有几个答案用指令集基于栈还是寄存器来解释，错了。Python主要不是慢在这里。

我们做个实验。最简单的整数循环：

和未优化的C比较一下：

我把执行路径上的宏和函数都加进来了。所以图中出现的就是在前面的例子里，LOAD_FAST要经过的全部代码。其中TARGET和FAST_DISPATCH是每条字节码都有的纯解释开销，而中间的代码是实际干活的部分。如果没有开tracing，最后会用computed goto直接跳到下一条指令的处理代码。

希望读者对LOAD_FAST这样一条比较简单的指令的工作量有了感性认识。

接着看STORE_FAST:

前面出现过的宏/函数我就不再次重复了。STORE_FAST需要把变量原来的值的引用计数减一，所以多出了Py_XDEFREF这一串代码，比LOAD_FAST要复杂些。注意右下角，如果引用计数减到0，就要调用对象的tp_dealloc方法来释放对象。这里具体调用的函数取决于对象的类型，在上面的例子里是int，所以会调用long_dealloc。所以我把这个函数标成红色，表示这条字节码不是一定调用这个函数，而是取决于对象的类型。

接下来是LOAD_CONST:

由于常量没有像局部变量那样用C数组存放，需要调用tuple的方法去拿，稍微比LOAD_FAST复杂一点。

顺便看几个典型的栈操作指令：

实现都相当简单。

如果把基于栈的虚拟机改为基于寄存器，理论上可以节省的就是上面这些代码。但是要注意LOAD/STORE系指令里实际干活的部分（比如Py_XDECREF）很可能省不掉。确定能省掉的是TARGET和FAST_DISPATCH这种纯解释开销和POP_TOP/ROT_THREE这种栈操作指令（但是又要增加寄存器间复制的指令）。

看完了可以省掉的指令，来看看真正干活的，无论如何不可能通过单纯把指令集改成基于寄存器就省掉的指令吧。INPLACE_ADD:

真是一图胜千言...

跟一遍这个执行过程，你还觉得前面那些LOAD_FAST/STORE_FAST省不省的，重要吗？对比LOAD_FAST和INPLACE_ADD的图，你还认同“这个循环指令集A要9条指令，指令集B只要4条，所以B一定比A快很多”这种思路吗？

还是解释一下：

和Lua对比的话，我没看过Lua VM的代码，引用别的答案里的代码：

和上图对比一下。

所以Python为什么慢？一个整数加法，用C就是一条机器指令，Lua大概十几行C代码，而Python需要经过近百行C代码。这些代码都干啥了？

我们再做个profile实测一下。Python VM的源代码用configure --enable-profiling配置，就会在编译时加入gprof的测量代码。下面是运行测试代码的结果：

PyEval_EvalFrameEx是字节码解释器循环所在，耗时43%。我们前面分析过，把指令集从基于栈改为基于寄存器，循环体最多能省一半指令，而且由于FAST_DISPATCH和DISPATCH的差别，这一半指令的解释开销较低。因此我们可以粗略地估计这种“优化”改进空间的上限是20%。

而其后10个耗时最多的函数里，PyObject_RichCompare和long_richcompare用来实现COMPARE_OP，其它的都属于INPLACE_ADD（和其后的STORE_FAST里必然发生的long_dealloc）。这两条指令就占用了54%的时间。

实际上不只是整数运算，作为面向对象语言最核心的“调用方法”和“访问对象自身属性”两个操作，Python也是非常慢。这个我有空再补充。

总的来说，Python性能为什么这么差？性能好的语言大体分两类：

而对Python设计者来说，有太多因素排在性能之前：易学，灵活性（比如加法的各种定义方法），概念简单（比如把int/long合并成一个任意精度整数类型）。即使有人愿意砸钱，设计者也不见得配合你，比如提出各种与性能优化相悖的向后兼容要求...